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I . INTRODUCTION 

In today's combat environment, the United States 
military and its allies find themselves in the midst of the 
information age they helped start. Information and systems 
that use information abound in all parts of the services and 
all locations on the globe. No longer can the. side with the 
best trained and best equipped force be confident of 
victory. If an opponent can conduct efficient information 
operations, they have a significant edge. An important fact 
is that information operations take place throughout the 
spectrum of combat, from peacetime operations such as 
refugee relief to armed conflicts similar to Operation 
Desert Storm. This fact implies we will always conduct 
information operations, regardless of the place or time. 

Information operations are "Actions taken to affect 
adversary information and information systems while 
defending one's own information and information systems." 
[DTIC] Information systems are normally the computer 
systems that receive, manipulate, and disseminate 
information. From this definition of information operations 
we realize these operations are both offensive and defensive 
in nature. An astute information operator could use 
propaganda in an offensive manner to destroy the public 
support of his enemy. Or, the operator could publish 
incorrect information about an operation in order to deceive 
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the enemy. Properly conducted, information operations are a 
powerful combat force multiplier that can significantly 
increase our ability to shape the environment and influence 
decisions at all levels of combat. 

To influence decisions, commanders and their staffs 
need the most up-to-date information available. This 
information comes from many different sources, but 
especially from computer systems. The Department of Defense 
(DoD) developed many of these computer systems over the last 
few decades before interoperability became a concern. Often 
systems cannot pass information to each other because they 
use incompatible message sets. 

One agency within DoD that tries to solve joint war- 
fighting problems is the U.S. Joint Forces Command (JFCOM) . 
A subordinate element of JFCOM is the Joint Battle Center 
(JBC) in Suffolk, Virginia, which tries to resolve Command, 
Control, Communications, Computers, Intelligence, 
Surveillance, and Reconnaissance (C4ISR) issues, especially 
between the various information systems. Part of their 
C4ISR involvement is the assessment of new technology to 
solve interoperability problems between the services. 

Many of the established information systems use message 
formats that possess a structured, though limited method of 
communication. Information is passed via a set of messages 
contained in a message set. These sets are rigid by design 
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and cannot be changed. However, one format cannot satisfy 
the needs of the entire DoD, not to mention our allies. 

Commanders need all possible information in order to 
make accurate and timely decisions. The various information 
systems contain valuable data, but it cannot reach the 
commander because of incompatible data formats between 
information systems. Thus, there exists a need to increase 
the flow of information to the commanders, yet save 
development time and costs due to budget constraints. We 
believe DoD can continue to use the legacy systems if some 
method is developed that allows message passing between the 
computer systems . 

We seek to design a format that bridges the differences 
between all the message formats called the Consolidated Type 
Hierarchy (CTH) . The CTH is formed from all the message 
formats contained in the network of information systems, 
thus allowing a free-moving flow of information to all 
systems that desire it. 

One new technology that has emerged recently is the 
extensible Mark-up Language (XML) . With roots in the 
publishing industry (the Standard Generalized Markup 
Language) , XML is now used by the e-commerce industry to 
allow interoperability between a variety of databases in a 
near-real time manner. Though these applications are 
business oriented, the application of XML shows great 
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promise in solving some of the DoD interoperability 
problems. We used XML to implement the CTH in our thesis. 

By using the CTH model, we believe DoD can start 
integrating the legacy computer systems with significant 
cost savings. Our results on a small set of messages show 
the concept has promise and hope for interoperability. 
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II. CURRENT STATE OF AFFAIRS 



One of the main difficulties in information operations 
is the task of getting relevant information to the user in 
the correct format . Many of our current systems are 
heterogeneous systems that do not communicate outside of 
their own format. Thus, we need the ability to share data 
with computer systems that were developed for diverse user 
communities with very different data needs and requirements. 
We are currently limited to sending text messages common to 
the various computer systems, and some systems cannot even 
do that . 

A. A MEGAPROGRAM 

We can think of attempts to continually use legacy 
systems and their information as an example of 
megaprogramming [GW92 ] . Megaprogramming is a concept 
developed by the Defense Advanced Research Projects Agency 
(DARPA) as part of an effort to reuse systems that already 
exist. A megaprogram is a software program that utilizes 
commercial off the shelf (COTS) , and government off the 
shelf (GOTS) software systems as if they were modules. The 
modules, or megamodules as the authors call them, are 
internally homogeneous, independently maintained software 
systems managed by a community with its own terminology, 
goals, knowledge and programming traditions. We call the 
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concepts, terminology, and interpretation associated with 
each domain specific megamodule an ontology. 

Unlike the distributed federated databases used in 
[GW92] , our legacy system megamodules possess only the 
ability to export information through a set of standardized 
messages. This constitutes a key difference between tying 
together legacy systems and the megaprogramming previously 
envisioned. Megaprogramming relies heavily on databases to 
furnish the ability to import and extract data from the 
heterogeneous systems, whereas our system must rely on the 
information sources to push the information out. We have no 
mechanism to actively query or pull information from the 
source. This limits our ability to access information 
within the megamodule. 

Because some systems cannot automatically extract data 
from a distant machine, they are reliant on other machines 
to send regular updates consisting of any new data they 
find. This feature is unfortunate because the remote 
systems are not always configured to meet the needs of the 
other systems. In some cases operator action is required to 
send and receive information from the source. System 
operators must then rely on standard operating procedures 
(SOPs) for regular updates of information outside of our 
local system. This does not agree with the mega -programming 
concept as stated in the paragraph above. This makes reuse 
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of legacy systems a limited example of mega -programming, but 
still useful. 

B . MESSAGE FORMATS 

In previous years, information systems defined a set of 
messages for each system. This set of messages contained 
the information most commonly needed by consumer systems, 
and was often domain specific. One common message format 
used by many systems is the United States Message Text 
Format (USMTF) . The U.S. and our NATO allies used USMTF to 
increase our ability to communicate tactical and other 
information. The format of USMTF is well established, but 
its fixed field format wastes bandwidth by sending empty 
information. Because USMTF messages require larger 
bandwidth capabilities than most land forces possess, the 
land forces use variants of USMTF. USMTF may also provide 
more information than the destination system needs. 

Coalition Information exchange (CIX) is a newer data 
message format constructed by Defense Information Systems 
Agency (DISA) with more capabilities than the Over the 
Horizon Gold (OTH-G) message format used by the Navy and 
Marine Corps. However, unless the receiving system can 
translate from CIX, the information is unused and useless. 

To communicate between different message formats such 
as CIX and USMTF, current implementations use software 
programs called translators. The translator alters a system 
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message from one legacy computer system format into another 
format for a different legacy system. The translator is 
implemented via a third generation language such as C++ or 
Ada. Providing some way for different existing systems to 
share data presents an opportunity to save significant 
development costs in the design of replacement systems built 
to share data. Enabling systems to share data also saves 
end-user time, since data does not have to be entered by 
hand from one format or system into another. 

However, making translators is a time consuming task 
when constructed manually. [Sin98] The programmer must map 
the systems' message types, find corresponding messages, 
find data within the message that can translate between 
systems, and finally code the translator from scratch. Once 
completed, the translator only works from one message format 
to another specific message format. Although these 
translators are better than the manual transportation of 
data between systems, their creation is time consuming and 
of limited use. Each translator is expensive because of the 
specialized knowledge contained in the two systems. This 
also causes maintenance problems when the programmer leaves 
or a heterogeneous system changes its message format . 

At this time, we do not possess an automated way of 
resolving representational differences between systems. 
Thus, the programmer must still complete the mapping by 
hand. We seek to construct a translator that uses a pre- 
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runtime developed framework to perform run-time message 
translation. This method would enable reuse of common 
translation routines, and would be able to translate 
messages among many different formats. 

C . BACKGROUND RESEARCH 

Part of our research revealed the similarities between 
integration of heterogeneous databases and legacy system 
integration. Since message formats share data among 
systems, we can consider messages to be results from a 
database query. Many current commercial databases share 
data between heterogeneous systems connected via networks. 
Reconciling differences between databases must be done over 
several levels. 

At the highest level, databases must be reconciled over 
different schemas. Database schemas define the structure of 
the data, and how each piece of data is related to each 
other, how it's organized. The differences include 
resolving the representations between the tables found in 
each database . [HMS] This representational heterogeneity is 
defined as "variations in the meaning in which data is 
specified (for the data) and (the way it is) structured in 
different components". It is a natural consequence caused 
by creating independent data structures. [HM99] 

The next level of reconciliation involves the naming 
conventions used in each database. A major cause of 
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conflicc is the use of homonyms and synonyms. Homonyms use 
the same word for different concepts, such as "fire." In 
one context, the phrase results in artillery rounds 
impacting on a target, while in another context, the phrase 
summons the fire deparrment. Synonyms describe the samte 
object, but use different terms. Soldiers commonly use 
position and location to mean the sam.e place. 

Representational differences make up a third level for 
reconciliation. As shown in Figure 2-1, one community may 
define a geospatial position using the Military Grid 
Reference System, while another defines the position using a 
latitude /longitude representation. Both methods define the 
sarnie real world object, but implement different methods and 
possess different attributes. 




Scm.e other causes of differences in data representation 
include the low-level format of the data, such as precision 
or units of measurement . [KM9 8] Another cause is the range 
of values for a data type, which may vary from system to 
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system depending on the needs of the user and the hardware 
and software the user possesses. Older systems cannot 
represent larger numbers due to the size of the allocated 
memory or the processor used in the hardware . 

D . PREVIOUS ATTEMPTS 

Because of the many different systems and formats we 
are looking for a systematic way to construct translators, 
which opens the door to automation. This will save time, 
money, and results in more reliable communications. 

In our search for a solution to the problem, we found 
several systems that try to achieve similar results. 

One thing that almost all these systems or models have 
in common is the use of some kind of universal 
representation of data, or some universally agreed upon 
vocabulary. Most systems have these universally accepted 
terms and build on that in different ways. 

1 • Canonical Data Model 

Roantree, Keane, and Murphy call their universal model 
a Canonical Data Model (CDM) . This is similar to a 
universally agreed upon representation for a location. They 
introduced a model containing three layers. From top to 
bottom, the layers are: the Federation Layer, the Component 
Layer, and the Integration Layer. They use the lowest layer 
to isolate the effects of changes in a member database. The 
Integration Layer changes with the database in order to 
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maintain a consistent interface with the upper layers. Any 
time a change is made in the design or schema of a 

particular constituent database, its corresponding 

integration layer changes. [RKM] 

2 . Metadata 

Another approach presented by Narinder Singh is to use 
metadata, which is information about data, to dynamically 
determine how to respond to a query. In this system, 
information providers must supply a description of the 
information they have to offer in terms of a standard 
vocabulary. This standard vocabulary is a list of 

universally agreed upon set of words, each word having a 
single meaning. Middleware provides access to the data 

sources. When a query is submitted from a user, the 

Tesserae Integration Engine dynamically creates a search 
plan and retrieves the information. [Sin98] 

One drawback to this system is the time cost of 
creating a search plan on the fly. In a dynamic environment 
such as the web, the benefits would outweigh the costs; but, 
in our context there is no advantage to creating a search 
plan . 

These previous methods have their merits, and we have 
tried to incorporate some of their achievements into our 
system. For example, it is apparent that in order to 

reconcile information from different databases, there has to 
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be at least some a priori agreement on what some of the 
terms mean. However, our context is different from the 
typical scenario in which databases are being integrated, 
since we don't have the ability to query data sources, and 
we don't want to assume the existence of a central data 
store . 

E. RESPECTFUL TYPE CONVERSION 

One of the most pertinent articles to our research is a 
paper written by Jeannette Wing and John Ockerbloom 
[JMJOOO] . Their paper discussed the conversion of different 
types in such a manner that no data was lost. This pertains 
directly to interoperability because of the problems 
associated with data differences. 

In their paper. Wing and Ockerbloom assume a normal 
subtype and supertype inheritance relationship, and call an 
instance of a type an object. The types follow what is 
known as the Liskov substitution principle, which is 
outlined in the article. The Liskov substitution principle 
says that the subtype inherits the attributes of the 
supertype, and an instantiated object of the subtype acts 
the same as the supertype when the supertype's method is 
invoked. A respectful type converter will convert two 

subtypes with a common supertype ancestor while preserving 
the behavior observable through the interface of the common 
ancestor supertype . [JMJOOO] 
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Wing and Ockerbloom recognize type hierarchies may 
solve many interoperability issues by reducing the number of 
translators required from to 2*N translators. [JMJOOO] 
They base their examples on an assumption that only one type 
will exist per file, which is unlikely to occur in our 
messaging system. A message may contain a position and a 
text message that have different supertypes. Unlike the 
paper, we must construct translators that contain many 
different functions because our messages will contain many 
different types. 

Additionally, our system cannot actively retrieve 
information because of how the message systems are 
constructed. Rather, the information providers will push 
their data, as opposed to the data being pulled from its 
source. Therefore, a system that derives a search plan 
would not be appropriate . 

F. THE EXTENSIBLE MARK-UP LANGUAGE (XML) 

In order to construct our program, we needed a method 
that allowed us fo express information in a manner 
independent of any platform yet still capture the meaning of 
the data. We found the extensible Mark-up Language (XML) 
met these criteria. Since XML is a fairly new language, we 
searched for current examples that utilized XML commercially 
and in DoD. In order to understand these examples and our 
thesis, we must first explain what XML is. 
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1 . 



Me ta - Language 



XML is a meta language, which means it describes the 
data contained inside an XML document. XML separates the 
content of the document from the presentation of the data, 
which enables more programs to read the document. [PROXML] 
The separation occurs because XML only provides the means to 
describe the data, leaving presentation of the data to the 
receiver . 

Mark-up tags surround the data in an XML document . The 
tags are very similar to Hyper-Text Mark-up Language (HTML) 
tags, with an important exception. While XML tags may use 
all but a small set of characters, HTML tags are predefined 
and restrictive. Unlike XML, the HTML language possesses 
functions that tell an HTML browser how to display the data. 

Figure 2-3 is an example of how an XML document could 
describe a person. Note the document root mark-up tag 
entitled people, and how it surrounds the nested elements. 

<people>< ! --This is a comment block- -> 

<person> 

<f irstName>Brian</f irstName> 

<middleName> John</middleName> 

<lastName>Lyttle</lastName> 

</person> 

<person> 

</person>< ! --This is an empty person element using open and close 
tags--> 

</people> 

Figure 2-3 Sample XML Document 
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XML Trees 



2 . 

XML works by forming a tree from the data contained in 
the XML document. The document must possess a root node in 
order for the parser to construct a tree from the elements 
within the document. Elements may be nested repeatedly 
beneath the root node, and may contain duplicate element 
names at the same level within the tree . 

XML contains a powerful concept called a namespace that 
effectively allows homonyms. The namespace allows the 
writer to use the same name but with different associations, 
provided the writer distinguishes the namespaces. This 
allows the transformations and formatting functions at each 
viewer's platform to take the appropriate actions when 
parsing the document tree. [PROXML] 

3 . Parsers 

In order to take actions on an XML document, we must be 
able to construct the tree in memory. The software program 
that constructs the document tree is called a parser. It is 
not responsible for presenting data to the user, unlike 
HTML. The parser ensures the document is "well-formed", 
which means the document obeys the XML syntax rules . XML 
parsers are powerful tools freely available from several 
sources. Both Internet Explorer 5.0 and Netscape's Mozilla 
6.0 contain XML parsers in addition to HTML parsers. The 
IBM Apache Group (http://www.apache.org) wrote and provided 
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the source code for their Xerces processor for anyone to 
utilize for free. The Xerces parser is written in both C++ 
and Java, and is available for a variety of operating 
systems to include Windows, Linux, Unix, AIX, and Sun 
Solaris. The Xerces parser is the official parser of the 
World Wide Web Consortium (W3C) at this time, and is fully 
compliant with the approved W3C recommendations. It does 
not expand upon the approved requirements of the W3C for 
XML. 

4 . Validation 

All of the parsers mentioned above are examples of a 
validating parser. Validating parsers verify the XML 
document obeys more stringent rules than the generic XML 
syntax. These rules are specified in a Document Type 
Definition (DTD) or a Schema. DTDs and schemas allow us to 
specify rules about what elements may appear in a document, 
the structure of the tree, and to a limited extent, what 
format (e.g. the order and number of occurrences) the 
elements must follow. DTDs and schemas serve the same 
purpose. They were designed to facilitate content checking, 
to some degree. Obeying the DTD ensures all users of our 
namespace can read our document using the same standard. 
The DTD is a W3C recommendation; schemas are only a W3C 



candidate 


recommendation . 


According to 


the 


W3C, "a 


Candidate 


Re c omme nda t i on 


is work that 


has 


received 
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significant review from its immediate technical community. 
It is an explicit call to those outside of the related 
Working Groups or the W3C itself for implementation and 
technical feedback. " Also, "a Recommendation is work that 
represents consensus within W3C and has the Director's stamp 
of approval . W3C considers that the ideas or technology 
specified by a Recommendation are appropriate for widespread 
deployment and promote W3C's mission." [W3C] However, 
schemas were designed to make up for some of the 
shortcomings of DTDs; and tools that support schemas are 
already on the market . 

Schemas have several advantages over DTDs . Schemas 
allow open content models. An open content model provides 
extensibility to a schema. This means that I can reuse 
someone else ' s schema. If their schema doesn't contain all 
the elements I want to include in my schema, I can add 
elements. This allows greater reuse of schemas. Open 
content models are optional; however, and a closed content 
model can be specified in a schema if desired. 

Schemas also provide some support for data types. Data 
types can be specified for elements and/or attributes. 
Beyond the typical data types found in common programming 
languages, the following data types are some of those 
supported: string, id, idref, nmtoken, nmtokens, entity, 
entities, enumeration, and notation. 

Other advantages of schemas [MSDN] -. 
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♦ Greater specificity of the number of occurrences of 
an element . 

♦ Ability to specify if sub-elements must appear in a 
certain order. 

♦ Accessible from Microsoft's Document Object Model. 

♦ Schemas are well -formed XML documents (unlike DTDs, 
which have their own syntax) . 

We believe that although schemas are relatively new, 
their additional capabilities provide them a substantial 
advantage over DTDs. We recommend the use of schemas. 

5. Transformation 

If two users have different formats for their data, 
like many Defense organizations, we can transform the XML 
document using the extensible Stylesheet Language 
Transformation (XSLT) . XSLT enables us to translate between 
vocabularies as well as merge existing resources. We can 
determine the correct stylesheet to use at runtime to 
dynamically translate between documents. We do not have to 
write procedural language code for most applications, 
although it may be necessary in some cases. 

Stylesheets provide a major contribution toward 
achieving our goals. They are a part of the XML world, and 
as such, share many of the same benefits. They can be 
transferred using the ubiquitous hypertext transfer protocol 
(HTTP) . They can be applied to XML documents by the XML 
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processors. The XML processors are COTS, and are available 
for free. Stylesheets can also refer to other stylesheets. 
Therefore, they can be used and reused in a modular way, 
also providing cost savings. 

Internet Explorer 5.0 and the MSXML 3.0 parser allow 
the programmer to write procedural JavaScript functions in 
order to assist with transformation. We have not found any 
other free commercially available parsers that allow us to 
do this in a packaged format, though we can construct a 
parser from source code like Xerces and write functions in 
the same manner. 

However, this requires a compiler for each target 
machine for the functions each programmer may write. 
Parsers perform much of the work contained by the XML 
language, and a good working parser should not be modified 
greatly. The commercial parsers such as Internet Explorer 
and Mozilla provide the functionality we need for this 
demonstration . 
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III. XML USAGE EXAMPLE SYSTEM 



A. THE JBMI EXPERIMENT 

One organization with XML experience is the Joint 
Battle Center (JBC) based in Suffolk, Virginia. JBC is part 
of Joint Forces Command (JFCOM) , and is charged with finding 
joint solutions for Command, Control, Communications, 
Computer, Intelligence, Surveillance, and Reconnaissance 
Systems (C4ISR) inter-operability. In order to fulfill this 
mission, they conduct experiments with several organizations 
each year. 

We witnessed Phase Two of an experiment entitled the 
Joint Battle Management Initiative (JBMI) . JBMI sought to 
prove XML is a valid technology for improving inter- 
operability and inter-connectivity between systems. All 
four services provided computer systems for the experiment. 

JBC defined two different levels of sharing information 
between systems in accordance with the Defense Information 
Infrastructure Common Operating Environment (DII COE) . 
Interoperability at its highest level allows systems to 
import and export information as if the remote site were 
actually part of the user's system. Inter-connectivity is 
several steps lower, and allows systems to pass limited 
messages between different systems. 
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The computer systems at JBMI accurately reflected the 
problem in DoD today. The primary system was the Global 
Command and Control System (GCCS) , which controls high level 
operational units across DoD. It specifically targets units 
the equivalent of an Army Brigade level or higher. It 
utilizes CIX as its means of message passing. The Navy and 
Marine Corps also sent their versions of GCCS/ which are 
compatible with the other services' GCCS systems. 

The U.S. Army provided a system entitled the Advanced 
Field Artillery Tactical Data System (AFATDS) . AFATDS is a 
member of the Army Battle Control System set, and is the 
command and control system for all ground fire-support 
systems in both the Army and Marine Corps. AFATDS also 
interacts with our English and German allies using its own 
specific format developed many years ago. It can send and 
receive a limited number of USMTF messages. 

In an interesting twist, JBC integrated two devices 
currently available on the commercial market. The first was 
a Palm Pilot V, which is a personal digital assistant. JBC 
programmed the simple USMTF Call for Fire and Observation 
Report messages into the PDA. They programmed the same 
ability into a cellular telephone, and communicated using 
the Wireless Application Protocol to the networked systems. 

All the systems connected via a hardwire LAN into a web 
server. The web server allowed each unique system to 
subscribe to a message set or an individual message type 
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from the USMTF . As each legacy system produced a message, a 
software wrapper transformed the message into an XML 
formatted message. It then sent the XML mark-up message to 
the web server. 

The web server received the message and removed the XML 
mark-up from the message. It parsed the message to discover 
the USMTF message type. The server then found a data 
directory specific to that message type, and saved the 
message. A Visual Basic monitor script periodically checked 
the directories for new information. If the monitor found 
new information, it checked a database to discover 
subscribers of that message type. 

If a subscriber was found, it called upon functions 
constructed in Java code to transform the message into the 
appropriate type. If the destination system required the 
message in the HTML format, the XSLT processor was called to 
make the conversion. Most systems subscribed for an HTML 
representation of the USMTF message or email. 

This system allowed the cell phone user to send a Call 
for Fire message to the AFATDS system via the web server. 
The AFATDS equipped unit could then provide indirect fire 
support onto the target. It also allowed the GCCS system to 
update its database, and the Air Force TCDB to enter the 
target information for use in plotting aircraft routes or 
further intelligence usage. 
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other abilities included at this demonstration were 



comma -delimited files used in spreadsheets and word- 
processing documents. Since many of our allies do not have 
the funds required to make military specific information 
systems, they must rely on Commercial Off The Shelf (COTS) 
products . 

An extremely useful application of COTS and XML was the 
target list used in the joint targeting process. Using 
AFATDS, a message containing a target list was sent to the 
web server. Upon receiving the message, the JBMI engine 
found the coalition subscribers that wanted a copy of the 
list. The engine translated the target list into a 
spreadsheet file, and sent it to the destination machine via 
email. Though the system lacked security restraints, it 
demonstrated the ability of XML to send various messages 
using COTS equipment . 

Given the accomplishments of the JBMI engine, we knew 
XML presented a means to accomplish interoperability between 
systems. It allowed messages to transform from native 
legacy format into XML and then be used in a different 
system. However, the engineers were required to write 
source line code in Java to accomplish this. We believe 
using XML and other COTS tools along with a different 
methodology can accomplish interoperability between systems 
cheaper and faster than writing source code. 



24 



B. ASSUMPTIONS 

We made several assumptions in our thesis. We assumed 
all the messages we received were well -formed XML documents 
and complied with a DTD for that specific message type. We 
assumed this because each system should send messages in the 
correct format, else it would not be fielded to the force. 
The parser would not read messages with incorrect formats 
because it would fail the validity check when a stylesheet 
or a DTD was applied to it. In a fielded system, a failed 
message would be returned to the sender with the appropriate 
error message. This service would take a small amount of 
time, and not impact the performance of the system. 
Additionally, we did not think we needed to check for 
transmission errors because the TCP/IP protocol stack 
conducts those error checks for us. 

In our environment, we assumed an experienced software 
engineer would use the system. The messages will depart and 
arrive in an XML mark-up format of the original system 
message . 

While we knew the translator system could be 
implemented either in a point-to-point system or in a 
publish/subscribe architecture, we chose to implement the 
point-to-point system. Although not as robust as the 
publish/subscribe architecture, the point-to-point 
implementation is sufficient as a first step for a proof of 
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concept. The point-to-point implementation can then form 
the basis for subsequent implementations. In the point-to- 
point system, each system possesses a copy of the translator 
and a means of communicating to the other system. 

We assumed individual systems using this software would 
possess similar capabilities to our own, because our 
demonstration is based on the systems used by JBC during the 
JBMI exercise. That is, it would be a machine using Windows 
95, Windows NT, or Windows 2000. 

Given these assumptions and requirements, we can now 
describe the design of our system. 



26 



IV. THE CONSOLIDATED TYPE HIERARCHY 



As we introduce you to the Consolidated Type Hierarchy 
(CTH) , remember our goal: we are trying to achieve 
interoperability between legacy systems that have different 
views and representations of data. Our general approach is 
to set , up a common framework that we can use in ,matching 
data sources with potential consumers. Translations will be 
defined in terms of the framework before run-time, and will 
be applied at run-time. Since the legacy systems we have in 
mind traditionally have shared their data through messages, 
we will consider the message formats they use rather than 
the data stores internal to the systems themselves. Before 
we explain what the CTH is, we will discuss what we need in 
order to create a CTH, the environment. 

A . THEORY 

1. System Schemas 

Schemas provide a blueprint for the data to be shared. 
They can be thought of as Application Programmer Interfaces 
(APIs) . Each message format will have its own schema. It 
is our way of knowing what data is contained within and 
provided by that data source or consumed by that recipient . 

If we only had to be concerned with converting between 
two message formats, we could easily map data fields from 
one message format to the other. This simplified problem 
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would be trivial and not warrant further effort. However, 
as more formats are considered, the task becomes more 
complicated and requires considerably more work. If you had 
N different formats to reconcile with each other, direct 
mappings would be required. [JWJOOO] 

2 . The Global Schema 

The global schema is a global view of the data to be 
shared. It provides the context for data to be shared among 
systems. The elements of the system schema have a "kind-of" 
relationship with the elements of the global schema. For 
example, one element in the global schema might be a 
location. Although latitude-longitude and MGRS coordinates 
have different formats, they are both a kind-of location. 
They convey the same information. 

The real purpose of the global schema is to capture the 
structure of composite types. If we were to send a list of 
locations, it would be meaningless. We must put information 
in its context. In other words, a position is an attribute 
of some other thing, like a ship, a tank, or an aircraft 
route. The global schema captures the contexts in which it 
is used. 

3 . Consolidated Types 

Every element within the global schema is a 
consolidated type. In the example mentioned above, location 
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is a consolidated type and latitude-longitude and MGRS 
coordinates are legacy system subtypes. 

Consolidated types are more than just an abstraction. 
Consolidated types must have a concrete representation in 
order to gain the advantages offered by having them. It's 
important to consider the physical representation of a 
consolidated type with care. Consolidated types are derived 
from pre-existing subtypes that are to be reconciled. 
Therefore, one method of choosing a representation would be 
to adopt the representation of one its subtypes. However, 
we would like to be able to convert from a subtype to the 
consolidated type and back to the same subtype without 
losing any information. Consequently, is important to 
select the representation with the highest degree of 
precision. 

4 . The CTH 

The global schema represents a global view of 
information that is to be exchanged. It is a bridge format, 
which reduces the number of translations that must be 
defined. The elements of the global schema are consolidated 
types. The CTH does more than describe the structure of 
the global schema. It also contains the relationships 
between its elements and the elements of its constituent 
schemas. We introduce a separate term for the consolidated 
type hierarchy because neither the global schema nor its 
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elements capture both the structure of the consolidate types 
and their relationships with the elements of the various 
system schemas. 

Now that we have explained the theory of the different 
parts and their relationships, it's time to look at how we 
implemented and integrated these pieces. 

B. IMPLEMENTATION & EXAMPLE 

We have created a simple example to illustrate how the 
different parts of our system fit together to achieve the 
desired result . In our example we have two message formats 
that we want to reconcile. We invented the message formats 
for the purpose of this example, but they are adequate to 
show the relationships between the different parts of our 
system and how they are used. 

Both formats carry information about tactical units in 
a battlespace. The Army message format is designed to 
contain information about ground forces. Originally 
constructed as a voice message, it is now a standard digital 
message as well. The Navy message format contains data 
about ships sent via tactical data links from a variety of 
sensors. Both messages contain information about objects 
the operators are observing. 

1 . Schemas 

The schemas were simply implemented as XML schemas. 
For our purposes, the essential requirement was to be able 
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to capture the structure of the data. This could have been 
done in many different ways, including UML diagrams. 
However, since DTDs or XML schemas can also be used for 
validating the XML documents, they might already exist for 
some systems and they could serve a dual purpose. We prefer 
the use of schemas over DTDs for reasons given in chapter 3, 
and our example uses XML Schemas. 

Before we go further, we'd like to acknowledge a 
valuable tool we discovered in our research called XML Spy. 
XML Spy is the product of Altova GmbH, of Austria. It is an 
easy to use integrated development environment for XML, with 
authoring tools for XML documents, DTDs, schema, and style 
sheets. The product is available for download at 
WWW . xml spy . com and free thirty day trial downloads are 
available. We used XML Spy for all the XML and related 
coding for our examples. We have included partial screen 
shots of the program in Figures 4-1 through 4-3 below. We 
are using the program to show the schema, because it can 
display them in a graphical representation, rather than 
having to look at the code; however the code is included in 
the Appendices . 

The Army message format we called a SALUTE message. 
Figure 4-1 depicts the schema for the message format. The 
root element in the SALUTE schema is the element named 
SOURCE. The Type element contains information about the 
message type, and the GroundUnit element contains the 



31 



inf ormauion on the ground units. Note the symbology depicts 
that there can be a sequence of GroundUnit elements 
contained in a valid XML document. 




Figure 4-1 Schema for the Army Salute message format from XML Spy 
Figure 4-2 depicts the Navy message f orm.at . It has 
some fields that will map to the .4.rmy message f orm.at , and 
some that do not . 
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Figure 4-2 Schema for the Track Report message format from XML Spy 
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The global schema xn Figure 4-3 depicts a composite 
i^'iev; of the information provided by both message formats. 
Here you can see that Location is a consolidated type. 
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Figure 4-3 Global Schema from X>IL Spy 

Also, notice that we included elements in the global 
schemia, such as Course and Speed, which did not have a 
corresponding element in the Army schema. If a Navy system 



were to send a message to an Army system, the Army system 
has no use for such information. This begs the question, 
why include these elements in the global schemia? 

There are two reasons to include those elements in the 
global schema. The first reason relates to the comm.ent we 
made earlier about choosing the representation with the 
greatest precision. If we convert a Navy message to conform 



33 



to the global schema without those elements, we would lose 
the Course and Speed information in the process. If we then 
convert it back to the Navy message format, we can't get 
that information back. We threw away that information. We 
would like to be able to convert from any system format to 
the global format and back without losing any information. 

The second reason to include unique elements in the 
global schema is to make it easier to find compatible 
elements between schemas. Imagine that we decide to 
integrate a third message format into the global schema, and 
we left out Course, Speed and other elements unique to each 
of the preexisting Army and Navy schemas. If the new schema 
we want to introduce has elements that do correspond to the 
previously unique elements, we may never discover the 
correspondence, unless we also look for corresponding 
elements in the Army and the Navy message schemas. Instead, 
if we include all of the elements, then when we integrate a 
new schema, we will be able to discover the common 
information to be shared among systems, without having to 
analyze each system independently. 

2 . Consolidated Types 

We captured the consolidated types in an XML document 
we named CT.XML. Pictorially, you can think of CT.XML as 
shown in Figure 4-4. Each root node represents a 
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onsolidated 



type . 



Each child node depicts 



the 



corresponding eleinenr from a particular message format. 

CT.XML 

^ I A A 

Figure 4-4 Symbolic view of CTJCVIL 

Figure 4-5 is an excerpt from CT-XML, the XML 
representation of the consolidated type hierarchy. The full 
listing is included in Appendix ?. 

<Location> 

<TrackReport name= " Coordinates '' /> 

<Salute name="Location" 

upXl a t e = " Gr i d2 La t Long . xsl " 
dnXlate="LatLong2Grid.xsl''/ > 

</Location> 

Figure 4-5 The consolidated type Location from CT.XML 
Figure 4-5 shows how the consolidated type. 
Location, is entered. The outer-most element is the name of 
the consolidated type, which comes from; the global schema. 
The nested elements name the m;essage formats that have a 
kind-of Location. Since both track report m.essages and 
salute m.essages have attributes that are a kind-of location, 
they are both listed here. Each of the nested elements may 
have between one and three attributes. The name attribute 
specifies the namie of the corresponding element in their 
respective m.essage formats. The upXlate attribute contains 
the nam.e of the style sheet that will translate from the 
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enclosing message format to the format of the consolidated 
type. The style sheet named in the dnXlate attribute will 
perform the reverse operation, taking an instance of a 
consolidated type, and transforming it to conform with a 
specific message format. 

Like many other aspects of our implementation, there 
were alternate ways of implementing the mappings between 
message formats and the global schema. One disadvantage of 
the way we implemented it is that searching through CT.XML 
for the translations would be slow compared to other 
methods, such as a table lookup or database query. But, 
since CT.XML will be searched when the stylesheets are 
generated, which happens prior to run-time, the speed of the 
search will not affect run-time performance. 

C . CTH USE 

Figure 4-6 shows a conceptual view of the CTH. The 
Army schema is in the upper plane, and the global schema is 
in the lower plane. The dashed arrows represent the 
associations and the translations between elements in the 
global schema and the Army schema, information that is 
stored in CT.XML. We have only included the Army Salute 
schema in the figure in the interest of readability, but we 
could have presented another plane for the Navy Track Report 
schema as well . 
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Army Salute Schema 




Global Schema 



Figure 4-6 Conceptual View of the CTH. The Army schema is in the upper plane, and the global 

schema in the lower plane. 
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This is all we need to have a translator. 



When a 



translator receives a message it could determine the format, 
then recursively apply translations defined in the CTH by 
the arrows. Currently we create stylesheets before run-time 
based on the information contained in the CTH. At run-time 
we let the XSL processor act as our translator using the 
stylesheets to give it processing instructions. 

1. Before Run-Time 

a ) Mapping 

The CTH is a framework for matching potential data 
sources and consumers. It enables the sharing of that data, 
despite representational differences. When a system is 
introduced into a network, a schema for the data it exports 
and/or imports must be available or must be produced so that 
its elements can be mapped to the global schema. In our 
work, we performed this by hand. 

In our system we generated the initial global 
schema from the Navy schema. Then we integrated the Army 
schema into this initial global schema. We will walk 
through the steps we followed during this process. 

We started with the root element in the Army 
schema and looked for a corresponding element in the global 
schema. We descended through the structure of the Army 
schema, establishing these correlations at every level 
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possible. When we mapped the Army Schema to the global 
schema, we established these relationships: 



Army Schema Element Name 


Global Schema Element Name 


GroundUnit 


Track 


Size 




Activity 


Status 


Location 


Location 


GridID 




Northing 




Easting 




UnitID 


Number 


Time 


GMT 


Equipment 




DistanceInKms 


DistanceInMiles 



Table 4-1 Initial Mapping of Elements in the Army Schema to the Global Schema 



As you can see, Size and Equipment in the Army 
schema did not have corresponding elements in the global 
schema, so we added them to the global schema and we add 
them to CT.XML as consolidated types. GridID, Northing, and 
Easting also did not have corresponding elements in the 
global schema; however, we did not add those elements to the 
global schema as we did with Size and Equipment. This is 
where an engineer will have to decide whether to incorporate 
the elements into global schema, or define a translation at 
a higher level that will perform the conversion. Table 4-1 
shows the mappings between the two schemas at this stage. 



39 



Army Schema Element Name 


Global Schema Element Name 


GroundUnit 


Track 


Size 


Size 


Activity 


Status 


' Location 


Location 

Translations : 

Grid2LatLong . xsl 
LatLong2Grid . xsl 


GridID 


Northing 


Easting 


Unit ID 


Number 


Time 


GMT 


Equipment 


Equipment 


DistanceInKms 


DistanceInMiles 



Table 4-2 Initial Mapping of Elements in the Army Schema to the Global Schema 



b) Translating 

When the mapping is complete, the engineer needs 
to determine which of two types of translations are 
required. The two types of translations are those that 
consist of nothing more than an element name change; and 
those that require a change in the data. Since XSLT 

facilitates modularity, some of the latter types of 
translations might already be defined. In our example, we 
defined translations that converted from grid to lat-long 
and back, and made the appropriate entries in CT.XML. 
Figure 4-5 shows the CT.XML entry for Location. Although 
our stylesheets do not actually convert a grid position to a 
latitude and longitude position, the intent here is to 
outline the process of reconciling a schema with the global 
schema . 
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Once each element's translation is defined, a pair 
of stylesheets can be generated that will translate from the 
particular message format to the global format, and back 
down, as in Figure 4-7. 

Let's look at one of the stylesheets to see how 
the translations are defined in XSLT and how the process of 




Figure 4-7 Generation of the Stylesheets 



generating the stylesheet could be automated once the 
mapping has been completed. (This explanation assumes the 

reader is somewhat familiar with the way that stylesheets 

work. ) 

Our example comes from Appendix G, which is a 
stylesheet that transforms an Army SALUTE message (Appendix 
A) into the global CTH foDrmat. The first significant 
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instruction is on line 9. Line 9 tells the processor to 
look for an element named SOURCE in the XML document to be 
translated. We used SOURCE as a root node that would be 
common to all schemas, or message types. Nested in the 
SOURCE element is the element named Type, which we also used 
as an element common to all message formats. They serve as 
an identifier for the source and message type. Lines 10 
through 13 are what the processor will output when a SOURCE 
element is found by the processor. Line 11 is significant 
because it specifies the schema that the output XML document 
must conform to, GlobalSchema .xsd. Given that the SOURCE 
and Type elements are standard elements in all messages, and 
given the schema for the output message, an automated 
stylesheet generator could produce this code in a 
stylesheet . 

Lines 18 through 3 0 tell the processor how to 
translate a GroundUnit element. They tell the processor 
that the equivalent name in the global schema is a track, 
and they specify the order in which to process the children 
of the GroundUnit element. It is important for the sub- 
elements to appear in the output document in the correct 
order so that the document conforms to the global schema. 
Notice that the order of the output elements is specified in 
terms of the source schema element names, except lines 24 
through 26. Those lines correspond to elements in the 
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global schema that have no equivalent element in the Salute 
schema . 

A program could automatically generate this XSL 
code as well. The name correspondences between the schemas' 
elements are contained in CT.XML. The order in which the 
sxab-elements should be processed is specified in the output 
schema, in this case the global schema. 

Recall that earlier we said there are two basic 
types of translations. One type of translation merely 
involves a name change, and the other translation involves a 
change in the data. Most of the translations contained in 
Army2Global .xsl are of the former type. However, the 
translation from MGRS coordinates to latitude/longitude 
coordinates does require a change in the data. Line 5 is an 
import instruction to the processor. When the processor 
sees line 5, it effectively reads the stylesheet 
Grid2LatLong .xsl and pastes it in place of the import 
statement. Again, the information required for this line is 
contained in CT.XML. Incidentally, we chose to use the 
import statement to demonstrate modularity of stylesheets; 
however, we could have just done the copy-paste operation 
ourselves, or a program that generates the Army2Global 
stylesheet could do it. 

We used JavaScript to perform the conversion from 
miles to kilometers, but we were unable to use the import 
functionality of XSL because of it. We'll discuss those 
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efforts later in this chapter. For the present discussion 
our aim has been to show the content of Army2Global . xsl , and 
that it could be generated automatically. 

2 . During Rxm-Time 

Sending a message from System A to System B involves 
two translations. The first translation will transform the 
message from System A's format to the global format, the 
upward translation. The second translation will convert 
from global to System B's format, the downward translation. 
Both translations could be performed on either side of the 
transmission, as long as they're done in the proper order. 
That is, both could be done by the sender's translator, both 
by the receiver's translator, or one on each side. 

There are two basic problems with doing both the upward 
and downward translations at the source. First, the source 
translator would have to know who all the recipients are, 
along with the appropriate translation for each. It would 
perform the upward translation and then it would have to 
perform downward translations for every different type of 
recipient, and send out multiple versions of the same data. 
The second potential problem is that changes in a consumer's 
schema might require the use of a new stylesheet that 
performs the new downward translations. Now we have to 
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worry about how to disseminate the new stylesheet to every 
source that produces information for the modified consumer. 

The problem with performing both upward and downward 
translations at the consumer is essentially the same as the 
second issue, above. We must have a method of disseminating 
changes in a producer's upward translations to each of its 
consumers. Furthermore, both methods would involve- some 
kind of lookup table that would be used at run-time in order 
to identify the appropriate stylesheet to apply to an 
outgoing or incoming document . 

It is much simpler however, to perform the upward 
translation at the source and the downward translation at 
the receiver. This implementation eliminates the 
complications posed by the other two. Only one version of 
the document has to be sent. No lookup tables are required 
because producers always apply the same upward translations 
to their outgoing messages, and consumers always apply the 
same downward translations to incoming messages. Also, 
changes to producer and consumer schemas are localized. 
Figure 4-8 is a collaboration diagram showing how the system 
would work. 

The CTH will not solve every problem by itself. 
Translations will still have to be written for many 
conversions between consolidated typ©s and data contained in 
specific message formats. What the CTH will do for us is 
vastly reduce the number of translations that must be 
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defined, and in some cases enables reuse of those 
translations. It may also provide a framework for semi- 
automated generation of the translations. 




Figure 4-8 Collaboration Diagram of Proposed Implementation 
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D . RESULTS 

We tested our system using a series of steps, 
incrementally checking what's been advertised about XML 
against what we were able to achieve. We started by 
creating two XML documents, one to represent a fictitious 
Army message format Appendix A, and the other. Navy, 
Appendix B. We created schemas for them. Appendices C and 
D, respectively. Next, we created a global schema that 
incorporated elements from both message formats. Figure 4-3 
and Appendix E. Then we created CT.XML, Appendix F, to show 
the relationships between the elements of the global schema 
and its constituent schemas. 

After entering correspondences between the message 
formats within CT.XML, we created the stylesheets to 
translate from the Army SALUTE message directly into the 
Navy Track Message. The main goal at this step was to 
verify the performance of an XSL processor. To execute the 
translations, we used a freeware program named Xalan 
constructed by IBM Apache Group (http://xml.apache.org/). 
Xalan is an XSL processor written in a variety of languages 
for different operating systems. The program takes command 
line parameters to specify the input and output XML 
documents , and which stylesheet to apply . The program and 
the stylesheet worked, and we also found that the resulting 
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message conformed to TrackSchema, which is the schema 
defined for the Navy Track Message. 

Our next step was to create four stylesheets that 
performed the upward and downward translations for both Army 
and Navy message formats. We wanted to test the ability to 
translate from Army to Navy via the global schema, and 
perform the reverse. We also wanted to test the modularity 
of the stylesheets; so, we created two more just to handle 
the translation of positions, going from MGRS format to 
latitude-longitude format. 

However, translating from MGRS to latitude-longitude 
requires the use of capabilities the W3C implementation does 
not support. Functional code is required in order to 
perform calculations on the data contained by an XML 
document . The Microsoft implementation of XSL supports 
JavaScript and Visual Basic Script (VBScript) functions that 
provide this capability. It uses the xslreval statement to 
invoke script functions from those two languages, but it 
does not support the import or include instructions as 
outlined in the W3C XSL namespace. [MSDN2] We implemented 
some of the final stylesheets (Appendices I and Q) using the 
xslreval processing instruction to demonstrate that XSL is 
capable of invoking a functional transformation for a user's 
specific needs, such as converting miles to kilometers .We 
converted the miles element into kilometers using 
JavaScript's math library. The stylesheet invokes the 
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commands using xslieval, which then searches for the 
language, specified in the second line of the stylesheet, as 
in Appendix I. Since this is an ability that Microsoft 
implemented for their own XSL processor, MSXSL [MS] , the 
Xalan processor does not process the xsl:eval command. 
Table 4-3 is a listing of all the files we used, and their 
purpose . 
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Appendix 


File Name 


Description 


A 


ArmyMe s s age . xml 


Message generated by an Army system. Valid 

in accordance with SALUTEschema . xsd 


B 


NavyMe s sage . xml 


Message generated by a Navy system. Valid 

in accordance with TrackSchema . xsd 


C 


SALUTEschema . xsd 


XML schema for validating messages generated 
by an Army system. 


D 


TrackSchema . xsd 


XML schema for validating messages generated 
by a Navy system. 


E 


GlobalSchema .xsd 


Contains the global view of data to be 
shared. Puts consolidate types in context. 
Also used for validating messages translated 
into the global schema. 


F 


CT . xml 


Contains the relationships between the 
elements of the global schema and the 
elements of the Army & Navy schemas. (Not 
used at run-time) . 


G 


Army2Global . xsl 


Translates an Army message into a global 
message. 


H 


Navy2Global .xsl 


Translates a Navy message into a global 
message . 


I 


Global2Army . xsl 


Translates a global message into an Army 
message . 


J 


Globa l2Navy .xsl 


Translates a global message into a Navy 
message . 


K 


Grid2LatLong .xsl 


A stylesheet module. 


L 


LatLong2Grid .xsl 


A stylesheet module. 


M 


NewGlobal .xml 


An Army XML document that has been 

translated into a global XML document. 


N 


NewNavy .xml 


An Army XML document that has been 
translated to a global, and then to a Navy 
XML document . 


0 


NewGlobal2 . xml 


A Navy XML document that has been translated 
into a global XML document . 


P 


NewArmy . xml 


A Navy XML document that has been translated 
to a global, and then to a Navy XML 
document . 


Q 


Army 2 Global .xsl 


Translates an Army Message into a Global 
message using Javascript commands 



Table 4-3 Listing of files used in example 
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V. 



CONCLUSIONS 



The purpose of our research was to find a means of 
communication between legacy systems, preferably using XML. 
While we were successful in the very limited demonstration 
of our consolidated type hierarchy, more work must be done 
to prove its applicability in C4ISR systems. This research 
was a first step, and should be followed by incorporating 
more functional transformations into the stylesheets, and 
then the application of the CTH to a set of real message 
formats . 

The biggest advantage offered by the CTH is the 
reduction in the number of translations that must be 
defined. This advantage is realized by using a global, or 
bridge format for the various message types. Another 
significant benefit from the CTH model is the opportunity to 
automate part of the process of defining the translations. 
Automation could play a role at different stages in the 
generation of the stylesheets. 

First, it is possible to create tool support for 
identifying elements in the new schema that correlate to an 
element in the global schema. [SC99] proposes a method for 
reconciling databases through semantic and structural 
matching. Since XML is a meta-language and is extensible, 
descriptive element names can be used, which lends itself to 
some level of syntactic matching between schemas. Since XML 
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also captures the structure of the data, structures can also 
be compared between schemas in order to find potential 
matches. Such a tool would identify possible matches in a 
graphical display, allow the engineer to confirm, override, 
or manually identify matches; and then make the appropriate 
entries in the global schema and CT.XML. 

Another tool that ^ would make the CTH. easier to use- is 
automated generation of the stylesheets. Once a message 
format has been mapped to the global schema, and the 
translations for individual elements have been identified in 
CT.XML, then the program should be able to automatically 
generate the stylesheets that translate entire messages to 
and from the global schema. All of the necessary 
information would be contained in the three documents of 
CT.XML, the global schema, and the system schema. 

Another potential area for future work is to create a 
tool that would search a library of stylesheets in order to 
facilitate reuse of those transformations. 

The best method of implementing the CTH may be in a 
publish/subscribe architecture. As the different systems 
log into the networked battlefield, the system would request 
to receive messages of a certain type. As each individual 
legacy system sends data over the network, a wrapper would 
intercept the message. The wrapper would mark up the 
message into a CTH XML representation, then send it to a web 
server. The web server would check the list of valid 
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subscribers for that message format, and send the message to 
those destinations. The destination system's XML wrapper 
would translate from the CTH mark-up form into the correct 
legacy system format. 

By reutilizing the legacy systems similar to the mega- 
programming concept, we hope to save DoD thousands of 
dollars from cost savings and cost avoidance. Growing a 
Consolidated Type Hierarchy from our model will enable a 
variety of systems to communicate information across the 
battlefield regardless of branch or nationality. 

The CTH is a powerful model that will allow more than 
just message systems to exchange information. It could be 
used for object-oriented databases, as well as source code 
files and initially any other kind of data. An application 
of this nature would allow more reuse of previously 
developed code and reduce development time and costs. An 
issue that remains to be investigated is the degree of 
overhead relative to real-time constraints and optimization 
methods for mitigating time and space overhead. 
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APPENDIX A-ARMYMESSAGE.XML 



This is the source file for the Army SALUTE message in 
XML. This was an input to translator along with a 
stylesheet, and was transformed into a global message, 
"NewGlobal .xml" . 



<!-- edited with XML Spy v3.5 NT beta 2 build Dec 1 2000 (http://www.xmlspy.com) by Brian Lyttle (Home) -> 
<!-This file captures the representation of an Army SALUTE Report. It is used when soldiers find an enemy on the 
battlefield, and 

report the enemy's activity. The Army constructed the report before automation, but today it still contains the same 
information. 

The information is structured like this: 

S: Size of the enemy unit, ie people, vehicles. 

A: Activity of the enemy, ie walking, emplacing, sleeping. 

L: Location in Military Grid Reference Position, with Grid identifier. Northing, and Easting. 

U: Unit identification, to include distinctive symbols, patches, vehicle numbers. 

T: Time the activity was observed. 

E: Equipment the enemy possessed during the activity, such as M60 Machine Guns, AK-47s, mortars--> 
<SOURCE name="ArmySystem" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" 
xsl:noNamespaceSchemaLocation=".\newSALUTESchema.xsd”> 

<Type MsglD="SALUTE7> 

<GroundUnit> 

<Size>10</Size> 

<Activity>WalkingNE</Activity> 

<Location> 

<GridlD>NK</GridlD> 

<Northing>100</Northing> 

<Easting>400</Easting> 

</Location> 

<UnitlD>1 50MRR</UnitlD> 

<Time>21 59Z</Time> 

<Equipment>AK_47sampAT</Equipment> 

<DistancelnKms>10</DistancelnKms> 

</GroundUnit> 

<GroundUnit> 

<Size>5</Size> 

<Activity>RunningNE</Activity> 

<Location> 

<GridlD>NK</GridlD> 

<Northing>50</Northing> 

<Easting>350</Easting> 

</Location> 

<UnitlD>100MRR</UnitlD> 

<Time>21 59Z</Time> 

<Equipment>M1 6</Equipment> 

<DistancelnKms>25</DistancelnKms> 

</GroundUnit> 

</SOURCE> 
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APPENDIX B-NAVYMESSAGE.XML 



This is the source file for the Navy Track Report message 
in XML. It shows what a Track Report would look like in 
XML. 



<!--The Navy TrackReport possesses a set of tracks that identify objects. The objects are identified by a variety of 
sensors such as Airborne radars and shipboard sensors. They communicate 

information to each other via Tactical Data Links (TADIL) in a near real time fashion. The computers on-board the 
sea and air platforms receive the infomration via the TADIL link, and use them in the information system as part of 
a display for the operator. The display contains a picture of all nearby objects detected by the sensors. Our 
representation is a simplified version used for our puposes to demonstrate the abilities of the CTH. 

The entries for track are: 

Number: the number given to the object by the TADIL system. 

Coordinates: the latitude/longitude position of the object. 

Course: the direction (in degrees) of the object 
Speed: how fast the object is traveling in miles per hour 
Status: tells if the object is friendly, enemy, or unknown. 

IFF: the Identification Friend or Foe code that is received from the beacon on the object. 

GMT: time of the last sighting of this object, in Greenwich Mean Time.-> 

<SOURCE name=’’NavyMessage" xmlns:xsi- 'http://www.w3.Org/2000/1 0/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation=".\newTrackSchema.xsd"> 

<Type MsglD='TrackReport7> 

<Track> 

<Number>1 000</Number> 

<Coordinates> 

<Latitude>32-36N</Latitude> 

<Longitude>30-20W</Longitude> 

</Coordinates> 

<Course>0</Course> 

<Speed>14</Speed> 

<Status>Unknown</Status> 

<IFF/> 

<GMT>1502</GMT> 

<DistancelnMiles>100</DistancelnMiles> 

</T rack> 

<T rack> 

<Number>1 1 1 1 </Number> 

<Coordinates> 

<Latitude>32-35N</Latitude> 

<Longitude>30-21 W</Longitude> 

</Coordinates> 

<Course>0</Course> 

<Speed>14</Speed> 

<Status>Unknown</Status> 

<IFF/> 

<GMT>1503</GMT> 

<DistancelnMiles>10</DistancelnMiles> 

</Track> 

</SOURCE> 
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APPENDIX C-SALUTESCHEMA.XSD 



This is the XML Schema for the Army SALUTE Report, 

" SaluteSchema . xsd" . It defines the structure of the 
"ArmyMessage . xml " document. This is the code represented by 
Figure 4-1. 



<?xml verslon="1.0" encoding=”UTF-8’’?> 

<!- edited with XML Spy v3.5 NT beta 2 build Dec 1 2000 {http://www.xmlspy.com) by Brian Lyttle (Home) -> 
<!-W3C Schema generated by XML Spy v3.5 NT beta 2 build Dec 1 2000 (http://www.xmlspy.com)-> 
<xsd:schema xmlns:xsd="http://www.w3.org/2000/1 0/XMLSchema" elementFormDefault-’qualified"> 
<xsd:element name="SOURCE"> 

<xs d : com pi exT y pe> 

<xsd:sequence> 

<xsd: element name='Type”> 

<xsd:comptexType> 

<xsd: attribute name- ’MsglD" type-'xsd: string" use="required"/> 

</xsd:complexType> 

</xsd:etement> 

<xsd:element name-'GroundUnif maxOccurs="unbounded"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd: element name-'Size" type- 'xsd :byte"/> 

<xsd:element name=" Activity" type="xsd:string7> 

<xsd:element name="Location"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name-'GridlD" type="xsd:string7> 

<xsd:etement name-'Northing" type-'xsd :string’V> 

<xsd:element name-'Easting" type="xsd:string"/> 

</xsd:sequence> 

</xsd : complexT ype> 

</xsd:eIement> 

<xsd:element name-'UnitlD" type="xsd:string7> 

<xsd:element name-Time" type="xsd:string'V> 

<xsd:element name="Equipment" type-'xsd :string"/> 

<xsd:etement name-'DistanceInKms" type="xsd:float"/> 

</xsd:sequence> 

</xsd;complexType> 

</xsd:eIement> 

</xsd:sequence> 

<xsd:attribute name-'name" type-'xsd rstring" use="required"/> 

</xsd : complexT y pe> 

</xsd:eIement> 

</xsd:schema> 
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APPENDIX D- TRACKS CHEMA.XSD 



This is the XML Schema for the Navy Track Report, 
"TrackSchema . xsd" . It defines the structure of 
"NavyMessage . xml " . This is the code represented by Figure 
4-1. 

<?xml version- ’1.0" encoding="UTF“8"?> 

<l- edited with XML Spy v3.5 NT beta 2 build Dec 1 2000 (http://www.xmlspy.com) by Brian Lyttle (Home) 
<!-W3C Schema generated by XML Spy v3.5 NT beta 2 build Dec 1 2000 (http://www.xmlspy.com)--> 
<xsd:schema xmlns:xsd="http://www.w3.org/2000/1 0/XMLSchema" elementFormDefault="qualified"> 
<xsd:element name-'SOURCE"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd: element name="Type"> 

<xsd:complexType> 

<xsd:attribute name-'MsglD" type-'xsd:string" use="required"/> 

</xsd: complexT ype> 

</xsd:eIement> 

<xsd:element name-'Track" maxOccurs-'unbounded"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name-'Number" type="xsd:string'7> 

<xsd:element name="Coordinates"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name-'Latitude" type-'xsd:string"/> 

<xsd:element name-'Longitude" type="xsd:string"/> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd:element name- ’Course" type="xsd:string"/> 

<xsd:element name-'Speed" type="xsd:string"/> 

<xsd:element name-'Status" type="xsd:string"/> 

<xsd:element name- ’IFF" type-'xsd:string"/> 

<xsd:element name-'GMT’ type="xsd:string"/> 

<xsd: element name-’DistancelnMiles" type=’’xsd:string"/> 

</xsd:sequence> 

</xsd :complexT ype> 

</xsd:element> 

</xsd:sequence> 

<xsd:attribute name-’name" type-'xsd:string" use="requlred’’/> 

</xsd:complexType> 

</xsd:element> 

</xsd:schema> 
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APPENDIX E-GLOBALSCHEMA.XSD 



This is the code from "GlobalSchema .xsd" . It is 
represented by Figure 4-3. The global schema defines the 
structure of a global message, as in "NewGlobal . xml " and 
"NewGlobal2 . xml " . 



<?xml version- ’1.0“ encoding=''UTF-8”?> 

<!- edited with XML Spy v3.5 NT beta 2 build Dec 1 2000 (http://www.xmlspy.com) by Brian Lyttle (Home) ~> 
<!— W3C Schema generated by XML Spy v3.5 NT beta 2 build Dec 1 2000 (http://www.xmlspy.comj-> 
<xsd:schema xmlns:xsd="http://w\ww.w3.org/2000/10/XMLSchema" e!ementFormDefault-'qualified"> 
<xsd:e!ement name- 'SOU RCE"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd .element name='Type"> 

<xsd :complexT ype> 

<xsd:attribute name="MsglD” type=”xsd:string" use-'required'7> 

</xsd:complexType> 

</xsd:element> 

<xsd:element name='Track" maxOccurs="unbounded"> 

<xsd : complexT ype> 

<xsd:sequenc€> 

<xsd:element name- ’Number" type="xsd:string"/> 

<xsd:element name="GMT' type- ’xsd:string"/> 

<xsd: element name="Location"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name-'Latitude" type="xsd:string7> 

<xsd:element name- 'Longitude" type="xsd:string"/> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd:element name="Status" type="xsd:string"/> 

<xsd:element name-’Course" type="xsd:string'7> 

<xsd:element name="Speed" type="xsd:string"/> 

<xsd:e!ement name="IFF"> 

<xsd : complexT ype/> 

</xsd:e!ement> 

<xsd:e!ement name="Size" type="xsd:string"/> 

<xsd:element name="Equipment" type="xsd:string"/> 

<xsd:element name="DistancelnMiles" type="xsd:string"/> 

</xsd:sequence> 

</xsd : comp lexT ype> 

</xsd:element> 

</xsd:sequence> 

<xsd:attribute name="name" type- 'xsd:string" use="required"/> 

</xsd:complexType> 

</xsd:element> 

</xsd:schema> 
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APPENDIX F-CT.XML 



This file contains the relationships between the 
consolidated types found in the global schema and the 
elements found in the Army and Navy schemas. This is a 
concrete example of Figure 4-4. 

<?xml version- *1.0” encoding-'UTF-8"?> 

<ConsolidatedTypes xmlns=”www.nps.navy.mil/sw/CTH/Globar'> 

<Track> 

<TrackReport name-'Track" upXlate="Navy2Global.xsr' dnXlate-'Global2Navy.xsrV> 

<Salute name-'GroundUnit" upXlate=”Army2Global.xsr' dnXlate-‘Global2Army.xsr/> 

</Track> 

<Number> 

<TrackReport name="Number7> 

<Salute name="UnitlD" upXlate-'UnitlD2Track.xsl" dnXlate="Track2UnitlD.xsl7> 

</Number> 

<Location> 

<TrackReport name="Location7> 

<Salute name-'Location" upXlate=”Grid2LatLong.xsr' dnXlate=''LatLong2Grid.xsl7> 

</Location> 

<Course> 

<TrackReport name="Course7> 

</Course> 

<Speed> 

<TrackReport name-'Speed7> 

</Speed> 

<Status> 

<TrackReport name-‘Status7> 

<Salute name="Activity7> 

</Status> 

<IFF> 

<TrackReport name-'IFF7> 

</IFF> 

<GMT> 

<TrackReport name="GMr7> 

<Salute name-Time7> 

</GMT> 

<Size> 

<Salute name="Size7> 

</Size> 

<Equipment> 

<Salute name="Equipment7> 

</Equipment> 

<Latitude> 

<TrackReport name-'Latitude7> 

</Latitude> 

<Longitude> 

<T rackReport name- 'Longitude7> 

</Longitude> 

<DistancelnMiles> 

<T rackReport name- 'DistancelnMiles7> 

<SALUTE name="DistancelnKms7> 

</DistancelnMiles> 

</Consol IdatedT y pes> 
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APPENDIX G-ARMY2GL0BAL.XSL 



This XSLT stylesheet transforms an Army SALUTE report 
into a global message. When we applied this stylesheet to 
"ArmyMes sage .xml" the message produced was "NewGlobal .xml" 
Line numbers have been added to facilitate referral in the 
text . 



1 <?xml version="1.0” encoding="UTF-8'7> 

2 <xsl:stylesheet version="1.0" xmlns:xsl= http://www.w3.orq/1 999/XSL/Transform 

3 xmlns:fo=''http://www. w3.org/1 999/XSL/Format"> 

4 <!~Styiesheet to translate from Army SALUTE Report to a CTH message-> 

5 <xsl:import href="AGricl2LatLong.xsr7> 

6 <xsl:template match = "/"> 

7 <xsl:apply-templates/> 

8 </xsl:template> 

9 <xsl:template match="S0URCE"> 

10 <S0URCE name="GlobalMessage"xmlns:xsl="http://www.w3.org/2000/10/XMLSchema-instance" 

1 1 xsi:noNamespaceSchemaLocation="AGIobalSchema.xsd" > 

12 <xsl:apply-templates/> 

13 </S0URCE> 

14 </xsl:template> 

15 <xsl:template match- Type"> 

16 <Type MsglD-TrackReport"/> 

17 </xsl:template> 

18 <xsl:template match=”GroundUnit"> 

19 <Track> 

20 <xsl:apply-templates select="UnitlD7> 

21 <xsl:apply-templates select- Time'V> 

22 <xsl:apply-templates select- 'Location7> 

23 <xsl;apply-templates select="Activity7> 

24 <Course/> 

25 <Speed/> 

26 <IFF/> 

27 <xsl:apply-templates select="Size7> 

28 <xsl:apply-templates select="Equipment'7> 

29 </Track> 

30 </xsl:template> 

31 <xsl:template match="UnitlD"> 

32 <Number> 

33 <xsl:value-of select=''.'7> 

34 </Number> 

35 </xsl:template> 

36 <xsl:template match ='Time"> 

37 <GMT> 

38 <xsl:value-of select=".7> 

39 </GMT> 

40 </xsl:template> 
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41 <xsl:template match-'Location’'> 

42 <Location> 

43 <xsl:apply*templates/> 

44 </Locatlon> 

45 </xsl:template> 

46 <xsl:template match=”Activity"> 

47 <Status> 

48 <xsl:value-of select=".7> 

49 </Status> 

50 </xsl:template> 

51 <xsl:template match="Size”> 

52 <Slze> 

53 <xsl:value-of select- '.7> 

54 </Size> 

55 </xsl:template> 

56 <xsl:template match="Equipmenr> 

57 <Equipment> 

58 <xsl:value-of select- '.7> 

59 </Equipment> 

60 </xsl:template> 

61 </xsl:stylesheet> 
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APPENDIX H-NAVY2 GLOBAL. XSL 



This XSLT stylesheet transforms a Navy Track report into 
a global message. When we applied this stylesheet to 
"NavyMessage .xml " the message produced was "NewGlobal2 .xml " . 

<?xml version- '1.0” encoding- 'UTF-8”?> 

<xsl:stylesheet vers ion-' 1.0" xmlns:xsl="http://www.w3.org/1999/XSL/rransform" 
xmlns:fo- 'http://www.w3.org/1999/XSL/Format''> 

<!--Sty!esheet to translate from a Navy Track Report to a CTH message~> 

<xsl:temp!ate match = ''/"> 

<xsl:app!y-templates/> 

</xs!:template> 

<xsl:temp!ate match- 'S0URCE"> 

<S0URCE name-'GlobalMessage" xmlns:xsi- 'http://www.w3.Org/2000/1 0/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation-'.\newG!oba!Schema.xsd" > 

<xsl:apply-templates/> 

</S0URCE> 

</xsl:template> 

<xsl:template match =''Type"> 

<Type MsglD-TrackReport''/> 

</xs!:template> 

<xsl:template match- 'Track”> 

<Track> 

<xs!:app!y-temp!ates select="Number”/> 

<xs!:apply-templates seIect="GMT'/> 

<xs!:apply-templates select="Coordinates”/> 

<xsl:apply-templates select="Status”/> 

<xsl:apply-templates select="Course7> 

<xsl:apply-templates select- ’Speed''/> 

<xsl:apply-templates select- 'I FF''/> 

<Size/> 

<Equipment/> 

<xs!:apply-templates select="DistancelnMiles''/> 

</Track> 

</xsl:template> 

<xsl:template match="Number*'> 

<Number> 

<xsl:value-of select- '."/> 

</Number> 

</xsl:template> 

<xsl:template match-'Coordinates''> 

<Location> 

<xsl:apply-templates/> 

</Location> 

</xsl:template> 

<xsl:template match=''Latitude"> 

<Latitude> 

<xsl:app!y-templates/> 
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</Latitude> 

</xsl:template> 

<xsl:template match="Longitude"> 
<Longitude> 

<xsl:apply-templates/> 

</Longitude> 

</xsl:tennplate> 

<xst:template match=’'Course"> 
<Course> 

<xsl:value-of select- '.7> 
</Course> 

</xsl:template> 

<xsl:template match="Speed"> 
<Speed> 

<xsl:value-of select- '.7> 
</Speed> 

</xsl:template> 

<xsl:template match="Status”> 
<Status> 

<xsl:value-of select- 
</Status> 

</xsl:template> 

<xsl:template match- '1FF"> 

<IFF> 

<xsl:value-of select=".7> 
</IFF> 

</xsl:template> 

<xsl:template match-’GMr’> 

<GMT> 

<xsl:value-of select=”.7> 
</GMT> 

</xsl:template> 

<xsl:template match- ’DistanceInMiles" 
<DlstancelnMiles> 

<xsl:value-of select- '.7> 
</DistancelnMiles> 

</xsl:template> 



</xsl:stylesheet> 



APPENDIX I-GL0BAL2ARMY.XSL 



This XSLT stylesheet transforms a global message into an 
Army SALUTE report. When we applied this stylesheet to 
"NewGlobal . xml " the message produced was "NewArmy .xml " . 

<?xml version-'1.0” encoding="UTF-8"?> 

<xsl:stylesheet version="1.0" xmlns:xsl="http://www. w3.org/TRA/VD-xsl" language="JavaScript"> 

<!-Stylesheet to translate from a CTH message to an Army SALUTE Report~> 

<!- <xsl:import href-'.\LatLong2Grid.xsrv>~> 

<xsl:template match = T> 

<xsl:apply-templates/> 

</xsl:template> 

<xsl:template match="SOURCE"> 

<SOURCE name="ArmySystem" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" 
xsi;noNamespaceSchemaLocation=".\newSALUTEschema.xsd" > 

<xsl : a pply-tem pla tes/> 

</S0URCE> 

</xsl:template> 

<xsl:template match='Type"> 

<Type MsglD="SALUTE7> 

</xsl:template> 

<xsl:template match='Track"> 

<GroundUnit> 

<xsl:apply-templates select="Size7> 

<xsl:apply-templates select="Status'7> 

<xsl:a pply-tem plates select="Location7> 

<xsl:apply-templates select-' Number"/> 

<xs I : a pp ly-tempi ates s elect="G MT'/> 

<xsl:apply-tem plates select="Equipment"/> 

<xsl:apply-tem plates select="DlstancelnMiles"/> 

</GroundUnit> 

</xsl:template> 

<xsl:template match="Number"> 

<UnitlD> 

<xsl:value-of select="."/> * 

</UnitlD> 

</xsl:template> 

<xsl:template match="GMT"> 

<Time> 

<xsl:value-of select="."/> 

<yTime> 

</xsl:template> 

<xsl:template match="Location"> 

<Location> 

<xsl:apply-templates/> 

</Location> 

</xsl:template> 
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<xsl:template match="Latitude’’> 

<GridlD> 

</GridlD> 

<Northing> 

<xsl:value-of select=".7> 

</Northing> 

</xsl:template> 

<xsl:template match="Longitude"> 

<Easting> 

<xsl:value-of select- ’.7> 

</Easting> 

</xsl:template> 

<xsl:template match="Status"> 

<Activity> 

<xsl:value-of select- '.7> 

</Activity> 

</xsl:template> 

<xsl:template match="Slze"> 

<Size> 

<xsl:value-of select- '.'7> 

</Size> 

</xsl:template> 

<xsl:tem plate match=*’Equipment"> 

<Equipment> 

<xsl:value-of select- ’.7> 

</Equipment> 

</xsl:template> 

<xsl:template match- 'DistancelnMiles"> 

<DistancelnKms><xsl:eval>this.nodeTypedValue*(2.21)</xsl:evalx/DistancelnKms> 

</xsl:template> 

</xsl:stylesheet> 
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APPENDIX J- GLOBAL 2 NAVY. XSL 



This XSLT stylesheet transforms a global message into a 
Navy Track report. When we applied this stylesheet to 
'‘NewGlobal2 .xml " the message produced was “NewNavy .xml " . 

<?xml version-' 1.0" encoding="UTF-8"?> 

<xsl:stylesheet version="1 .0" xmlns:xsl="http://www.w3.org/1 999/XSL/Transform'' 
xmlns:fo="http://www.w3.org/1999/XSLyFormat"> 

<!--Stylesheet to translate from a CTH message to a Navy Track Report-> 

<xsl:template match = "/"> 

<xsl:apply-templates/> 

</xsl:template> 

<xsl:template match="SOURCE"> 

<SOURCE name-'NavyMessage" 

xmlns:xsi=''http://www.w3.org/2000/10/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation=".\newT rackSchema.xsd" > 

<xsl:apply-templates/> 

</SOURCE> 

</xsl:template> 

<xsl:template match="Type"> 

<Type MsglD="TrackReport"/> 

</xsl:template> 

<xsl:template match='Track"> 

<Track> 

<xsl:apply-templates select="Number"/> 

<xsl:apply-templates select=”Location"/> 

<xsl:apply-templates select="Course"/> 

<xsl:apply-templates select="Speed"/> 

<xsl:apply-templates select="Status"/> 

<xsl:apply-templates select-' I FF"/> 

<xsl:apply-templates select=''GMT"/> 

<xsl:apply-templates select=''DistancelnMiles"/> 

<U rack> 

</xsl:template> 

<xsl:template match=''Number"> 

<Number> 

<xsl:value-of select="."/> 

</Number> 

</xsl:template> 

<xsl:tem plate match-' Location"> 

<Coordinates> 

<xsl:apply-templates/> 

</Coordinates> 

</xsl:template> 

<xsl:template match="Latitude''> 

<Latitude> 

<xsl:apply-templates/> 

</Latitude> 
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</xsl:template> 

<xsl:template match="Longitude''> 
<Longitude> 

<xsl:apply-templates/> 

</Longitude> 

</xsl:template> 

<xsl:template match="Course''> 
<Course> 

<xsl:value-of select- '.7> 
</Course> 

</xsl:template> 

<xsl:template match- ’Speed''> 

<Speed> 

<xsl:value-of select=".7> 
</Speed> 

</xsl:template> 

<xsl:template match="Status"> 

<Status> 

<xsl:value-of select- '.7> 
</Status> 

</xsl:template> 

<xsl:template match="IFF"> 

<IFF> 

<xsl:value-of select=".7> 

</IFF> 

</xsl:template> 

<xsl:template match-’GMT’> 

<GMT> 

<xsl:value-of select- '.7> 
</GMT> 

</xsl:template> 

<xsl :template match- 'Distancel nMiles’’> 
<DistancelnMiles> 

<xsl:value-of select- ’.7> 
</DistancelnMiles> 

</xsl:template> 



</xsl:stylesheet> 
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APPENDIX K-GRID2LATL0NG.XSL 



This XSLT stylesheet is imported by "Army2Global . xsl " . 
This stylesheet does not actually convert a grid position 
into a latitude-longitude position. We used this stylesheet 
to test and demonstrate the modularity of XSLT stylesheets. 



<?xml version="1.0" encoding=”UTF-8"?> 

<xsl:stylesheet version="1.0" xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” 
xmlns:fo="http://www.w3.org/1999/XSI_/Format"> 



<xsl:template match- 'Grid I D''> 
</xsl:template> 

<xsl:template match="Northing”> 
<Latitude> 

<xsl:vaIue-of se!ect="."/> 
</Latitude> 

</xsl:template> 

<xsl:template match- 'Easting"> 
<Longitude> 

<xsl:value-of select-'."/> 
</Longitude> 

</xsl:template> 

</xsl:sty!esheet> 
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APPENDIX L-LATL0NG2GRID.XSL 



This XSLT stylesheet is imported by "Global2Army . xsl " . 
This stylesheet does not actually convert a latitude- 
longitude position into a grid position. We used this 
stylesheet to test and demonstrate the modularity of XSLT 
stylesheets . 



<?xml version-’I.O" encoding- 'UTF-8”?> 

<xsl:stylesheet version- '1 .0" xmlns:xsl- 'http://www.w3.org/1999/XSUTransform” 
xml ns :fo- ’http://www.w3.org/1999/XSUFormat”> 

<xsl:template match="Latitude”> 

<GridlD> 

</GridlD> 

<Northing> 

<xsl:value-of select-‘.”/> 

</Northing> 

</xsl:template> 

<xsl:template match="Longitude”> 

<Easting> 

<xsl:value-of select=”.7> 

</Easting> 

</xs!:template> 

</xsl:stylesheet> 
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APPENDIX M-NEWGLOBAL.XML 



This is the output of the XSL processor when 
"Army2Global .xsl ” is applied to " ArmyMes sage .xml " 
<SOURCE name="Globa!Message” xmlnsixsi- 'http://www.w3.org/2000/10/XMLSchema-instance'' 
xsi:noNamespaceSchemaLocation=".\newGlobalSchema.xsd"> 

<Type Msg!D="TrackReport"/> 

<Track> 

<Number> 

150MRR 

</Number> 

<GMT> 

2159Z 

</GMT> 

<Location> 

<Latitude> 

100 

</Latitude> 

<Longitude> 

400 

</Longitude> 

</Location> 

<Status> 

WalkingNE 

</Status> 

<Course/> 

<Speed/> 

<IFF/> 

<Size> 

10 

</Size> 

<Equipment> 

AK_47sampAT 

</Equipment> 

<Distance!nMiles> 

4.52488687782805 

</Distance!nMiles> 

</Track> 

<Track> 

<Number> 

100MRR 

</Number> 

<GMT> 

2159Z 

</GMT> 

<Location> 

<Latitude> 

50 

</Latitude> 

<Longitude> 

350 

</Longitude> 

</Location> 

<Status> 

RunningNE 

</Status> 

<Course/> 
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<Speed/> 

<IFF/> 

<Size> 

5 

</Si2e> 

<Equipment> 

M16 

</Equipment> 

<DistancelnMiles> 

11.3122171945701 

</DistancelnMiles> 

</Track> 

</SOURCE> 
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APPENDIX N-NEWNAVY.XML 



This is the output of the XSL processor when 
"Global2Navy .xsl " is applied to "NewGlobal .xml " 

<SOURCE name-'NavyMessage" xsi:noNamespaceSchemaLocation=".\newTrackSchema.xsd" 
xmlns:fo="http://www. w3.org/1999/XSL/Format" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"> 
<Type MsglD="TrackReport7> 

<T rack> 

<Number> 

150MRR 

</Number> 

<Coordinates> 

<Latitude> 

100 

</Latitude> 

<Longitude> 

400 

</Longitude> 

</Coordinates> 

<Course/> 

<Speed/> 

<Status> 

WalkingNE 

</Status> 

<IFF/> 

<GMT> 

2159Z 

</GMT> 

<DistancelnMiles> 

4.52488687782805 

</DistancelnMiles> 

</T rack> 

<Track> 

<Number> 

100MRR 

</Number> 

<Coordinates> 

<Latitude> 

50 

</Latitude> 

<Longitude> 

350 

</Longitude> 

</Coordinates> 

<Course/> 

<Speed/> 

<Status> 

RunningNE 

</Status> 

<IFF/> 

<GMT> 

2159Z 

</GMT> 

<DistancelnMiles> 

11.3122171945701 

</DistancelnMiles> 
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APPENDIX 0-NEWGL0BAL2 .XML 



This is the output of the XSL processor when 
"NavY2Global .xsl " is applied to "NavyMessage .xml " 



<?xml version- '1.0" encoding- 'UTF-16"?> 

<SOURCE name-'GlobalMessage" xsi:noNamespaceSchemaLocation=".\newGlobalSchema.xsd" 
xmlnsifo- 'http://www.w3.org/1999/XSL/Format" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"> 
<Type MsglD-TrackReport"/> 

<Track> 

<Number>1 000</Number> 

<GMT>1502</GMT> 

<Location> 

<Latitude>32-36N</Latitude> 

<Longitude>30-20W</Longitude> 

</Location> 

<Status>Unknown</Status> 

<Course>0</Course> 

<Speed>1 4</Speed> 

<IFF/> 

<Size/> 

<Equipment/> 

<DistancelnMiles>100</DistancelnMiles> 

</T rack> 

<Track> 

<Number>1 1 1 1 </Number> 

<GMT>1503</GMT> 

<Location> 

<Latitude>32-35N </Latitude> 

<Longitude>30-21 W</Longitude> 

</Location> 

<Status>Unknown</Status> 

<Course>0</Course> 

<Speed>14</Speed> 

<IFF/> 

<Size/> 

<Equipment/> 

<DistancelnMiles>10</DistancelnMiles> 

</T rack> 

</SOURCE> 
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APPENDIX P-NEWARMY.XML 



This is the output of the XSL processor when 
"Global2Navy .xsl " is applied to "NewGlobal . xml " 

<SOURCE name="ArmySystem" xmlns.xsi- ’http://www.w3.org/2000/10/XMLSchema-instance’’ 
xsi:noNamespaceSchemaLocation=”.\newSALUTEschema.xsd”> 

<Type MsglD=”SALUTE”/> 

<GroundUnit> 

<Size/> 

<Activity> 

Unknown 

</Activity> 

<Location> 

<GhdlD/> 

<Northing> 

32-36N 

</Northing> 

<Easting> 

30-20W 

</Easting> 

</Location> 

<UnitlD> 

1000 

</UnitlD> 

<Time> 

1502 
</Time> 

<Equipment/> 

<DistancelnKms>22K/DistancelnKms> 

</GroundUnit> 

<GroundUnit> 

<Size/> 

<Activity> 

Unknown 

</Activity> 

<Location> 

<GridlD/> 

<Northing> 

32-35N 

</Northing> 

<Easting> 

30-21W 

</Easting> 

</Location> 

<UnitlD> 

1111 

</UnitlD> 

<Time> 

1503 
</Time> 

< Equip me nt/> 

<DistancelnKms>22.1</DistancelnKms> 

</GroundUnit> 

</SOURCE> 
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APPENDIX Q-ARMY2 GLOBAL. XSL USING "XSL:EVAL'' 



This is file differs from Appendix G because it uses the “xsheval” command and does not use the import ability 
implemented in the w3c version of XSL. However, it does convert from kilometers to miles and still transforms 
MGRS to lat/long coordinates. 



<?xml version=”1.0" encoding=”UTF-8”?> 

<xsl:stylesheet version-' 1.0" xmlns:xsl- 'http://www.w3.org/TRA/VD-xsr language- 'JavaScript''> 

<I-Stylesheet to translate from Army SALUTE Report to a CTH message-> 

<!- <xsl:include href=”.\Grid2LatLong.xsr'/>-> 

<!-The include statement is an accepted statement in a different XSL namespace called 
xmlnsixsl- 'http://www.w3.org/1999/XSUTransform''. 

However, in the namespace used by this stylesheet, "include" and "import" are not accepted commands. Since we 
wanted to demonstrate the 

ability of XML to functionally transform objects, we selected the above namespace. The "XSL/Transform" 
namespace is used to transform the 

trees formed by the two documents, while the "TR/WD-xsl" namespace is used to format objects for a destination 
system. 

The w3c is reviewing different recommendations, and we hope the two namespaces are combined :).-> 
<xsl:template match=T> 

<xsl:apply-templates/> 

</xsl:template> 

<xsl:template match="SOURCE"> 

<SOURCE name-'GlobalMessage" 

xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" 

xsi:noNamespaceSchemaLocation=".\newGlobalSchema.xsd" > 

<xsl:apply-templates/> 

</SOURCE> 

</xsl:template> 

<xsl:template match="Type"> 

<Type MsglD="TrackReport"/> 

</xsl:template> 

<xsl:template match="GroundUnit"> 

<Track> 

<xsl:apply-templates select="UnitlD"/> 

<xsl:apply-templates select="Time"/> 

<xsl:apply-templates select="Location"/> 

<xsl :apply-templates select="Activity"/> 

<Course/> 

<Speed/> 

<IFF/> 

<xsl:apply-templates select="Size"/> 

<xsl:apply-templates select="Equipment"/> 

<xsl:apply-templates select="DistancelnKms"/> 

</Track> 

</xsl:template> 

<xsl:template match="UnitlD"> 

<Number> 

<xsl:value-of select="."/> 

</Number> 

</xsl:template> 

<xsl:template match-Time"> 

<GMT> 

<xsl:value-of select- '."/> 

</GMT> 

</xsl:template> 
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<xsl:template match="Location''> 
<Location> 

<xsl:apply-templates/> 

</Location> 

</xsl:template> 

<xs I : template match- 'Activity"> 
<Status> 

<xsl:value-of select=".7> 
</Status> 

</xsl;template> 

<xsl:template match="Size"> 
<Size> 

<xsl:value-of select=".7> 
</S(ze> 



</xsl:template> 

<xsl:template match="Equlpment"> 
<Equipment> 

<xsl:value-of select=".7> 



</Equipment> 

</xsl:template> 

<xsl:template match- 'Grid I D7> 

<xsl:template match="Northing"> 

<Latitude> 

<xsl:value-of select=".7> 

</Latitude> 

</xsl:template> 

<xsl:template match-' Easting”> 

<Longitude> 

<xsl:value-of select="."/> 

</Longitude> 

</xsl:template> 

<xsl:template match="DistancelnKms"> 
<DistancelnMiles> 

<xsl:eval>this.nodeTypedValue/{2.21)</xsl:eval> 

</DistancelnMiles> 

</xsl:template> 

</xsl:stylesheet> 
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